Ensuring smooth recovery of operations after downtime due to data loss or corruption, equipment failure, or complete site outage after a power loss, a natural disaster, such as an earthquake, a flood, a hurricane, or a tornado, for example, or a man-made problem, such as a spill of hazardous material, infrastructure failure, or sabotage, for example, is a significant challenge to data centers. Resuming operation at a data disaster recovery site, whether planned (such as a scheduled site migration) or unplanned (such as an accidental event), requires careful preparation. Planning for such contingencies could take months, while the execution of the plan may need to take place in minutes. Dozens or hundreds of steps need to be performed by the application, hardware, network, and storage teams. Any error, process flaw, routing issue, or other factors could delay the site recover.
To separate the site from the same risks posed to the client system, the remote disaster recovery site may be separated from the client system by many miles. The disaster recovery site may be in a different part of a city, a different city, a different state, a different country, or even a different continent than the client system, depending upon the risks to the client system and the budget of the client system, for example. This lessens the risk that a power failure, natural disaster, or man-made problem at the client system is also affecting the disaster recovery site.
The servers, desktop computers, laptop computers, and workstations at a client are referred to as client machines, while the servers, desktop computers, laptop computers, and workstations at a data recovery site are referred to as recovery machines. Client machines and recovery machines may be physical or virtual. The data images and unpersonalized operating system (“OS”) installed on disks of machines before purchase are referred to as an OS Image. The OS Image is personalized and turned into a host image for that machine, on startup. Applications may then be installed, data may be created, and the machine further customized. After the machine is configured and used, the OS and Data Images stored on a hard drive of a machine are referred to as a host image. In disaster recovery, a backed up copy of the host image is typically recovered to a recovery machine so that the host image may run on the recovery machine.
The known commercially available disaster recovery solutions have limitations. Some known commercially available conversion processes require a pre-configured destination machine or machines with the same hardware and/or operating system (“OS”) as the client machine, which adds significant cost and is slow. Others require that software be written to handle recovery to a predetermined type of recovery machine.
Site Recovery Manager, available from VMware, Inc., Palo Alto, Calif., for example, only enables recovery of applications running in virtual machines hosted on VMware ESX server by hypervisor. It is not possible to move a host image running on a failed physical machine to a virtual recovery machine and back to the physical machine or to another physical machine during failback from the disaster recovery data center back to the client system. Citrix Systems, Inc., Fort Lauderdale, Fla., has a similar product with similar limitations.
Windows® Server 2008 R2 Failover Clustering, an adaptation of Microsoft Cluster Service (MSCS), available from Microsoft Corporation, Redmond, Wash., allows supported applications to be clustered. This is a high availability solution that requires the cluster machines at the disaster recovery site to be up and running 24/7, in anticipation of a disaster. This can be quite expensive. The active cluster machines at the disaster recovery site require power, licensing, and maintenance.
RecoverTrac 2.0, available from FalconStor, Inc., Melville, N.Y., enables automatic recovery from a physical client machine to a physical recovery machine (physical-to-physical (“P2P”) recovery), as long as the two physical machines are of the same type (same type of hardware, same manufacture, and same operating system). RecoverTrac 2.0 also enables automatic recovery from a virtual client machine to a virtual recovery machine (virtual-to-virtual (“V2V”) recovery), and from a physical client machine to a virtual recovery machine (physical-to-virtual (“P2V”) recovery), for any certified hypervisor or physical platform, as long as the type of the client machine and the type of the recovery machine are known to the recovery system. In this case, conversions required to a host image or a recovery machine, including the replacement of storage drivers and the setting of IP addresses, as necessary, are hard coded in the software controlling the recovery process. The software is written based on the type of the client machine and the recovery machine, and their operating systems. Recovery jobs include local data recovery, such as bare metal recovery jobs, as well as remote data recovery, with both site failover and site failback orchestration.
In many instances, client machines are old and the same model of hardware is no longer commercially available. The client machines to be recovered are not always known to a disaster recovery site and the recovery machines are not always known to the client system prior to a disaster.